[レポート]サーバーレスアプリ用のロードバランサーの選択方法 #reinvent #NET301

re:Invent 2020のセッション「 Choosing the right load balancer for serverless applications 」を聴講しましたのでレポートします。

サーバーレスとありますが、on Fargateで稼働するECSやEKSについても扱っています。ELBファミリーの各サービスの差異や、Lambda、ECS、EKSをターゲットにする場合の注意点、またELBとAPI Gatewayの比較や、マイクロサービスのアーキテクチャーパターンについても述べられていて、非常に有意義なセッションでした。最下部に視聴リンクを置いていますので、より詳しく学びたい方はre:Inventにサインインした上でそちらをご確認ください。

セッション概要

Elastic Load Balancing automatically distributes incoming application traffic across multiple application targets for fault tolerance and load distribution. In this session, learn how to use the AWS load balancing services, Application Load Balancer and Network Load Balancer, with targets like AWS Fargate containers and AWS Lambda functions. The session also covers load balancing principles, how to pick the right load balancer, interesting use cases, and architectural best practices.

Elastic Load Balancingはアプリケーションの受信トラフィックを自動的に複数のアプリケーションターゲットに分配し、フォールトトレランスや負荷分散に役立ちます。このセッションではAWSの負荷分散サービスであるApplication Load BalancerやNetwork Load Balancerについて、またFargateコンテナやLambda関数のようなターゲットについて学習します。このセッションは負荷分散の原理、最適なロードバランサーの選び方、興味深いユースケース、アーキテクチャーベストプラクティスについても扱います。

• Session ID: NET301
• Session Level: Advanced - 300
• Speaker: Corina Motoi, AWS Senior Solutions Architect

レポート

Elastic Load Balancing (ELB)

Family

現在4種類

• Application Load Balancer (ALB)
  • L7層で機能
  • HTTP/HTTPSトラフィックに最適
• Network Load Balancer (NLB)
  • L4層で機能
  • ハイパフォーマンス・低遅延が求められる場合に最適
• Gateway Load Balancer (GWLB)
  • New!
  • 単一のトラフィックの出口と入口のように機能し、トラフィックを分散し、需要に応じて仮想アプライアンスをスケーリングする
• Classic Load Balancer (CLB)
  • レガシー / 他のものに移行検討を

ELBの基本的な仕組み

ELBファミリーはどれも

1. トラフィックは、プロトコルとポートが設定されたリスナールールに基づき受信される
2. ターゲットとして(EC2)インスタンスをサポート
   • ALB/NLBの場合IPアドレスやFargateコンテナもターゲットにできる
   • ALBであればLambda関数もターゲットにできる

Family間の比較

• 固定IPはNLBでのみ実現可能
• HTTPヘッダーベースでのルーティングはALBでのみ実現可能

より詳細を知りたい方は

昨年のre:Inventnの以下セッションを聴講ください

• AWS re:Invent 2019: Get the most from Elastic Load Balancing for different workloads (NET407-R2)

サーバーレスの分野における負荷分散

サーバーレスというと幅広いですが、このセッションに置いては、LBのターゲットとなりうる以下2サービス、LambdaとFargateにフォーカスします。 加えて、API GatewayとELBの各機能についても扱います。

Lambda as a target for ALB

Benefits / use cases

• EC2、コンテナ、Lambdaなど複数のコンピューティングサービスを組み合わせて使える
• content-base routing ruleやweighted target groupを使って複数のLambda関数にトラフィックをルーティングできる
• S3オブジェクトアップロード・ダウンロードのようなカスタムターゲットを作成できる

Good to know

• 各ターゲットグループには1Lambda関数しか設定できない
• Lambda関数とALBは同一アカウント、同一リージョンにある必要がある
• WebSocketは非対応
• Lambda関数に対するALBヘルスチェックはサポートされており、コンソールもしくはCLIで設定可能
  • ヘルスチェックでもLambda関数の課金は発生するので注意

Fargate (ECS) as a target for ELB

Benefits / use cases

• EC2、コンテナ、Lambdaなど複数のコンピューティングサービスを組み合わせて使える
• スパイキーで予測しにくいトラフィックパターンを持つマイクロサービスを作成する場合
• TCP/UDPベースのアプリケーション→NLBを使う
• 単一ALBの単一リスナー上に複数のサービスを使える

Good to know

• Dynamic host port mappingが可能(ALB)
• サービスは最大5ターゲットグループまでサポート
• ELB、コンテナヘルスチェック両方設定することを推奨

Fargate (EKS) as a target for ELB

Benefits / use cases

• k8sアプリケーションを稼働するのがより簡単に
• AWSがpodのライフサイクルを管理し、AWSがWorker Nodeを起動する
• クラスター外部からトラフィックを受け付けるのにのAWS Load Balancer Controller(旧名ALB Ingress Controller)が使える
  • ALBとNLBが利用可

Good to know

• AWS Load Balancer Controllerは単一ALBを複数のk8s ingress ruleで共有できる
• TargetGroupBindingというカスタムリソースを使って、Podを既存ターゲットグループに紐付けることができる
  • ALBがクラスター外にある場合に有効
• Podあたり最大4vCPUと30GBメモリーが設定可能
• 完全にプライベートなクラスターをサポート

the AWS Load Balancer Controller

AWS Load Balancer Controllerについては他にも色々あるので、詳しくは以下ブログポストをチェックしてください

• Introducing the AWS Load Balancer Controller

Containers roadmap

• Containers roadmap

API Gatewayとの比較

ルーティング

• API Gateway → Path-based routing
• ALB → Rule-based routing
  • HTTPリクエストヘッダー
  • URLパス
  • URLクエリ
  • それらの組み合わせ

Lambda関数と統合した場合のペイロード(リクエスト/レスポンス)

• API Gateway → 6MB
• ALB → 1MB

スロットリング

• API Gatewayにはあり、ALBにはなし

固定IP

• NLBの背後にALBを設置することで実現可能

スケーラビリティ

• API Gateway → 最大10,000 リクエスト/秒
• ALBは自動スケール

他サービスとの連携

• API Gateway → S3やSQSなどの他マネージドサービスのパブリックエンドポイントとの統合が可能、外部エンドポイントとも
• ALB → VPC内のプライベートリソースにトラフィックを転送したい場合に適している

AWS WAFによる防御

• API Gateway → REST APIでのみ可能。HTTP APIでは現在不可
• ALB → 可能

Architectural patterns

Serverless microservices with ALB

以下のように、ALB配下にECS on EC2な構成のマイクロサービスがあるとします。 マイクロサービスの新バージョンをECS on Fargateでデプロイしたい、とします。

Blue Greenデプロイメントを実現したい場合、ALBのweighted target groupが使えます。

最初は、旧版の重みを100、新版の重みを0に設定します。 徐々に新版の重みを増やしていき、 最終的に旧版の重みを0、新版の重みを100にします。

このような方法でゼロダウンタイムでサーバーレスへの移行ができます。

もちろんLambda関数をターゲットにすることもできます。

他にも、ALBの機能である固定レスポンス=ターゲットにトラフィックを転送することなしにALBから固定レスポンスを返す機能も便利です。

Multi Regionの場合

マルチリージョン構成の場合は、Route53やGlobal Acceleratorが複数リージョンに渡ってトラフィックを配分する際に使えます。

Serverless microservices with NLB

• ユースケース
  • HTTP・HTTPSではない場合
  • 高スループット
  • 低レイテンシー
  • 固定IPが必要

難しい点は、NLBの背後には1マイクロサービスしか配置できない点。そのため、マイクロサービスごとにNLBが必要になる。 こういった場合、NLBの後ろにALBを置くのがおすすめ。

詳細は以下のブログにあります。

• Using static IP addresses for Application Load Balancers

Exposing private microservices using APIGW

HTTP API Gatewayを使って、プライベートなマイクロサービスにプライベートアクセスしたい場合、API GatewayのALBとのプライベートインテグレーションが使えます。VPCリンクをAPI GatewayとALBの間に設置することでAPI GatewayがVPC内のプライベートリソースにアクセスすることを可能にします。

全リソースが同一アカウント内に存在する必要がある点は注意です。

REST API Gatewayを使って、プライベートなマイクロサービスにプライベートアクセスしたい場合はNLBを同様の方法で利用できます。 こちらも全リソースが同一アカウント内に存在する必要がある点は注意です。

複数のサービスを公開できるのがこの構成の便利な点のひとつです。NLBの背後のサービスごとにポートを指定することでサービスを定義できます。

視聴URL

• https://virtual.awsevents.com/media/1_zl42re5e